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Sir: 



In response to the Official Action dated October 3, 2003, reconsideration of the 
outstanding rejections is respectfully requested in view of the remarks beginning on page 2 of this 
Response. 



The Examiner objected at Section 1 of the Office Action that the invention of claim 
80 is known from the following parts of ITU-T G.707 of 03/96: Sections 3.3, 3.7, 3.10, 8.1.7.1, 
8.3.8, 9.3.1.6, 10.2, 10.2.1 and 10.2.3 and Figs. 8-8, 8-13, 8-14 and 10-19. 

With one exception, these parts of G.707 describe only the contiguously concatenated 
structures of the prior art. The Examiner seems to be confusing the contiguously concatenated 
structures described in the above parts of G.707 with the virtually concatenated structure of the 
present invention. In particular, the Examiner states that, in G.707, the acronym C-4-Xc refers to 
contiguous concatenation and VC-4-Xc refers to virtual concatenation. This is not the case: both 
C-4-Xc and VC-4-Xc are contiguous structures. C-4-Xc refers to a contiguously concatenated 
Container while VC-4-Xc refers to a contiguously concatenated Virtual Container. The Examiner 
is referred to the definition of "VC" at Section 3.3 at page 3 of G.707. 

By way of exception, both virtual and contiguous concatenated structures are referred 
to in Section 10.2.3 and Fig. 10-19. However, no information is given here or elsewhere in G.707 
as to how virtual concatenation is achieved. The Examiner is referred to Section 8.1 .7.2 at page 43 
of G.707 where the skilled reader would learn that the details of virtual concatenation are under 
study, i.e., not yet determined. 

In Section 5 of the Office Action, the Examiner puts forward a response to the 
applicants arguments filed in the previous response (filed July 2 1 , 2003). It is respectfully submitted 
that, for the reasons set out above, the parts of G.707 used here by the Examiner do not disclose 
virtually concatenated structures. Again, the one exception is G.707 Section 10.2.3 that does not 
disclose the virtually concatenated structure of claim 80 as also discussed above. 
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For the avoidance of doubt, the following claim 80 limitation is not taught by the 
reference: the use of a part of the POHof a virtually concatenated structure to indicate a sequence 
of frames in the virtually concatenated structure. 

Concerning the H4 byte, the Examiner considers Section 8.3.8 and Figs. 8-13 and 8- 

14ofG.707. 

Section 8.3.8 and Figs. 8-13 and 8-14 describe use of the H4 byte for multiframe 
indication in lower order TUs (i.e., tributary units). This has nothing to do with concatenation. A 
TU comprises a virtual container and a pointer. In lower order virtual containers (LO VC), the 
capacity allocated to the POH is too small to carry all the information required. To cope with this, 
the POH of a single LO VC is distributed over the single VC in four successive frames. The four 
successive frames are referred to as a multiframe. The H4 byte is conventionally used to indicate 
the first frame of a multiframe and that is what is being described here. Figs. 8-13 and 8-14/G.707 
illustrate this. 

The important distinction between a multiframe and concatenation of any kind is that 
a multiframe relates to a single VC, whereas concatenation relates to a plurality of VCs sharing a 
payload. This distinction is obvious when one considers that the multiframed VC can only carry the 
conventional payload for that VC, whereas concatenated VCs have the advantage of carrying a 
payload larger than that of a single VC. The Examiner is referred to the definition of 
"concatenation" at Section 3.9 at page 5 of G.707. 

To put it another way, the multiframe is concerned with the problem of insufficient 
overhead capacity in the relatively small LO VCs. Concatenation is concerned with the problem of 
carrying signals with a bandwidth greater than that of the largest available VC. 
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Conventional, contiguously concatenated structures described in G.707 use the TU 
pointer to achieve concatenation. This has a number of disadvantages, including the need to process 
the pointer at every stage along a path. The novel virtual concatenation solution provided by the 
invention of claim 80 and corresponding claims advantageously achieves concatenation using the 
path overhead that is only processed at the termination of the path, i.e., at the destination. As a 
result, the virtually concatenated structures of the present invention can be carried by the large 
installed SONET and SDH infrastructure without the modifications at intermediate nodes required 
to support contiguously concatenated structures. 

Allowance of all claims is respectfully requested. 

Wherefore, a favorable action is earnestly solicited. 

Respectfully submitted, 
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